% taken from hs's mary.tex, and tracing back to knuth.
\def\dash---{\kern.16667em---\penalty\exhyphenpenalty\hskip.16667em\relax}

\section{Rate Limiting with Topology Switching}
\label{sec:topology}

As described in \cite{topology}, the Topology Switching framework
directly configures the underlying physical network and switches to enable
different applications to meet their performance requirements based on
different tunable parameters. Applications can decide upon a metric to
optimize and choose their own routing scheme amoungst the different nodes
and switches in the network. The Topology Switching framework can then
re-configure the network parameters to suit the needs of the application. 
From amongst the different metrics that can be tuned by Topology Switching, 
we choose rate limiting as the mechanism for network allocation in our
implementation using Hadoop. This is partly due to the ease of
implementation, and partly due to the mechanism being similar to the
connection-based allocation performed by Orchestra, enabling a fair
comparison between the performances of the two approaches. 

The Topology Switching framework consists of a server which accepts
requests for creating a \emph{virtual network}. A virtual network is
desired configured network overlaid on the actual physical network. A
client stub also runs on each node in the cluster. Applications send their
requests to a local client, which forwards the request to the server on
behalf of the application. The server decides the optimal network
configuration based on the requirements specified by the application and
sends the necessary changes to each client stub on each of the affected
nodes in the cluster. The client stub is then responsible for locally
applying the changes as suggested by the server based on the requests of
the applications.

The TC associated with a given transfer contacts a local client stub with
the request for rate limiting on each flow of the transfer. This request is
supplied to the client stub in a JSON file. The JSON file contains a list 
of sources and a destination to which each of the sources needs to transmit
data. For each such destination in the transfer, an additional request is
issued. The client stub, in conference with the server, configures the
virtual network. Subsequent transfers between the nodes adhere to the rate
limits that are set. Since the current set of flows is a dynamic view and
constantly changes, the TC periodically updates the rate limits required to
maintain optimal performance and re-issues re-configuration requests.
